1. Technical Field
The embodiments herein generally relate to validation of hardware platforms, and, more particularly, to system and method for hardware platform validation driven by software.
2. Description of the Related Art
Typically, in every electronic products components like one or more micro-controllers, memories (RAM, ROM, Flash), peripherals such as USB controller, Ethernet controller, WiFi and application specific processors, including DSP are present. A “Hardware platform” refers to a system that is composed of components like above, designed for a specific product application like a mobile communication device or a network router.
Most of the electronic devices/products will have number of hardware functionalities and at some point for development of a hardware platform. Softwares are integrated to determine performance and functionality of the device. The hardware platform can be a real board (e.g., mother board). The hardware platform may be realized as the physical hardware as found in an end product (product silicon), or a test sample of the sample platform (sample silicon) or an FPGA based implementation of the sample platform (Emulator) or a simulation of the platform at RTL or behavior levels like SystemC (simulator). Post-si platform can either refer to product silicon and sample silicon, and pre-si platform refers to either emulator or simulator.
The cost of a bug or defect to identify and fix it increases drastically if it is found in later stages like product silicon as against early stage like simulator. These defects should be found and fixed as early as possible and should be tested thoroughly at each stage. The overall objectives of platform level testing can be roughly divided into structural tests, functional validation and performance validation. Structural tests are performed to determine any connectivity issues. Functional validation tests are done to check whether hardware platform functions as per the requirements and performance validation tests are done to check whether the hardware platform service requests within stipulated time.
In the existing technology hardware platform is checked for structural issues, and the product software is then tested on the platform that means both hardware platform and softwares are tested jointly. Since both platform and software can potentially have bugs, defect isolation can be tedious. The product software requires many cycles to execute a specific validation goal and in pre-si especially in simulation, this means considerable simulation time is required for each test. There also custom test software available in which a testing engineer maintains the test software which is different from product software which is then used to test the hardware platform before testing both jointly. However, this custom test software is not portable on to different platforms and it is also not possible to check complete use-cases.
FIG. 1 is a line diagram illustrating validation of hardware platforms in a typical system on chip (SoC) lifecycle. There are validation Gap due to (i) No “software-in-loop” during validation, (ii) Not possible to check complete use-cases which implies, can't exercise hardware as the final product software would. With reference to FIG. 1, FIG. 2 is a graphical representation illustrating a typical scenario of bug population per phase. Number of bugs decrease from Pre-Si->Product. But the cost associated with isolation, debug and fix increases considerably. Cost of lost opportunities due to bugs in product can be even high (50% of chips need additional unplanned tapeouts).
Accordingly, there remains a need for developing a methodology and associated tool for enabling functional and performance validation of hardware platforms, and reproduce issues in post-si at pre-si stages efficiently, and effectively identify and isolate defects that otherwise manifest in product silicon, cost and schedule efficient.